A content delivery network (CDN) distributes content (e.g., resources) efficiently to clients on behalf of one or more content providers, preferably via a public Internet. Content providers provide their content (e.g., resources) via origin sources (origin servers or origins), and a CDN can also provide an over-the-top transport mechanism for efficiently sending content in the reverse direction—from a client to an origin server. Both end-users (clients) and content providers benefit from using a CDN. Using a CDN, a content provider is able to take pressure off (and thereby reduce the load on) its own servers (e.g., its origin servers). Clients benefit by being able to obtain content with fewer delays.
End Users and Subscribers
In the following description, an end user is an entity (e.g., person or organization) that ultimately consumes some Internet service (e.g., a web site, streaming service, etc.) provided by a service provider entity. This provider entity is sometimes referred to as a subscriber in this description because they subscribe to CDN services in order to efficiently deliver their content, e.g., from their origins to their consumers. A CDN may provide value-added mediation (e.g., caching, transformation, etc.) between its subscribers and their end-users.
Clients and Origins
As used herein, clients are agents (e.g., browsers, set-top boxes, or other applications) used, e.g., by end users to issue requests (e.g., DNS and HTTP requests) within the system. When no CDN or other intermediaries are in use, such requests may go directly to the subscriber's own servers (e.g., their origin servers) or to other components in the Internet. When a content provider subscribes to CD services (described below), various requests may go to intermediate CD services that may map the end-user requests to origin requests, possibly transforming and caching content along the way.
Typically, each distinct origin (e.g., origin server) is associated with one subscriber, but a subscriber may be associated with any number of origins, including subscriber-owned and CDN provided origins.
The physical origins with which the CDN interacts may actually be intermediaries that acquire content from a chain of intermediaries, perhaps, e.g., elements of a separate content acquisition system that ultimately terminates at a subscriber's actual origin servers. As far as the internals of the CDN are concerned, however, the origin is that service outside the system boundary from which content is directly acquired.
Logical Organization
Services, Service Instances, and Machines
As used herein, a “service instance” refers to a process or set of processes (e.g., long-running or interrupt driven) running on a single machine. As used herein, the term “machine” refers to any general purpose or special purpose computer device including one or more processors, memory, etc. Those of ordinary skill in the art will realize and understand, upon reading this description, that the term “machine” is not intended to limit the scope of anything described herein in any way.
One or more service instances (of the same or different service types) may run on single machine, but a service instance is the execution of a single service implementation. As used herein, “service implementation” refers to a particular version of the software and fixed data that implement the single service instance. A service or service implementation may be considered to be a mechanism (e.g., software and/or hardware, alone or in combination) that runs on a machine and that provides one or more functionalities or pieces of functionality.
A service may be a component and may run on one or more processors or machines Multiple distinct services may run, entirely or in part, on the same processor or machine. The various CD services may thus also be referred to as CD components.
Those of ordinary skill in the art will realize and understand, upon reading this description, that the term “service” may refer to a “service instance” of that kind of service.
In some cases, it may be useful or necessary to distinguish between the code (e.g., software) for a service and an actual running version of the service. For the sake of this description, the code corresponding to a service is sometimes referred to as an application or application code for that service. Those of ordinary skill in the art will realize and understand, upon reading this description, that a machine may have code for a particular service (e.g., in a local storage of that machine) without having that service running on that machine. Thus, e.g., a machine may have the application code (software) for a collector service even though that machine does not have an instance of the collector service running. The application code for a service may be CDN resource (i.e., a resource for which the CDN is the origin).
There is no requirement that services running on a particular machine be of the same type. There is also no requirement that the services running on a particular machine, even if of the same type, be configured in the same manner, or be the same version. Thus, e.g., a particular machine may run two collector services, each configured differently. As another example, a particular machine may run a reducer service and a collector service.
Categorizing Services
A CDN may, in some aspects, be considered to consist of a collection of mutually interconnected services of various types. FIG. 1A depicts an exemplary categorization of major service types, and divides them into two overlapping categories, namely infrastructure services and delivery services. Infrastructure services may include, e.g., services for configuration and control (to command and control aspects of the CDN), and services for data reduction and collection (to observe aspects of the CDN). These services support the existence of the delivery services, whose existence may be considered to be a primary purpose of the overall CDN. In accordance with an embodiment, the delivery services are themselves also used as implementation mechanisms in support of infrastructure services.
Although not required, in preferred CDN implementations, it will likely be the case that, for most service types, service instances will not be isolated but will, instead, be grouped in some manner (e.g., into hierarchies or lattices) containing multiple instances of that service type. Thus, e.g., a CDN may comprise groupings of the various types of services (e.g., a grouping of control services, a grouping of reduction services, etc.) These homogenous groupings may include homogenous sub-groupings of services of the same type. Generally, these homogenous groupings form networks, generally comprising subnetworks.
Typical interaction patterns and peering relationships between services of the same and different types impose not only structure on the topology of a local service neighborhood but also on the topology of interactions between the homogenous subnetworks. These subnetworks may be internally connected or consist of isolated smaller subnetworks. In general, for service type T, this description will refer to the T network as that subnetwork of the CDN consisting of all service instances of type T, regardless of whether or not the corresponding subnetworks of type T are actually interconnected. Thus, e.g., the rendezvous network (for the rendezvous service type) refers to the subnetwork of the CDN consisting of all rendezvous service instances, regardless of whether or not the corresponding rendezvous service subnetworks are actually interconnected.
In general, for service type T, as used herein, the “T service(s)” or “T system” refers to the collection of services of type T, regardless of whether or how those services are connected. Thus, e.g., the “reducer services” refers to the collection of CD services of the CDN consisting of all reducer service instances, regardless of whether or not the corresponding reducer services (or service instances) are actually connected, and, if connected, regardless of how they are connected. Similarly, e.g., the “collector system” refers to the collection of CD services of the CDN consisting of all collector service instances, regardless of whether or not the corresponding collector services (or service instances) are actually connected, and, if connected, regardless of how they are connected; etc.
As used herein, a particular service of type T running on one or more machines may also be referred to as a “T” or a “T mechanism.” Thus a rendezvous service instance running on one or more machines may also be referred to as a rendezvous mechanism; a control service instance running on one or more machines may also be referred to as a controller or control mechanism; a collecting (or collector) service instance running on one or more machines may also be referred to as a collector or collector mechanism; and a reducer service instance running on one or more machines may also be referred to as a reducer or reducer mechanism.
It should be appreciated that as a particular machine may be running more than one kind of service, the naming of a service instance on a particular machine does not limit the machine from running other types of services.
Information Types
Each service or kind of service may consume and/or produce data, and, in addition to being categorized by CDN functionality (e.g., namely infrastructure services and delivery services above), a service type may be defined or categorized by the kind(s) of information it produces and/or consumes. In one exemplary high-level categorization of services, services are categorized based on five different kinds of information that services might produce or consume are defined, as shown in the following table (Table 1):
TABLE 1Service CategorizationCategoryDescription1(Abstract)Any information that can be delivered from server toDeliveryclient.2Configura-Relatively static policies and parameter settings thattiontypically originate from outside the network and con-strain the acceptable behavior of the network.3ControlTime-varying instructions, typically generated within thenetwork, to command specific service behaviors withinthe network.4EventsStreams (preferably, continuous) of data that captureobservations, measurements and actual actions performedby services at specific points in time and/or space in oraround the network.5StateCumulative snapshots of stored information collectedover some interval of time and/or space in or around thenetwork.
Each service or kind of service may consume and/or produce various kinds of data. Operation of each service or kind of service may depend on control information that service receives. As part of the operation (normal or otherwise) of each service or kind of service, a service may produce information corresponding to events relating to that service (e.g., an event sequence corresponding to events relating to that service). For some services or kinds of services, the data they consume and/or produce may be or include event data. Each service or kind of service may obtain state information from other CDN services or components and may generate state information for use by other CDN services or components. Each service may interact with other services or kinds of services.
FIG. 1B shows a generic CD service instance for each kind of service in a CDN along with a possible set of information flows (based on the service categorization in Table 1 above).
As shown in FIG. 1B, each service instance in a CDN may consume (take in) control information (denoted CTRL in the drawing) and may produce (e.g., emit or provide) control information as an output (denoted CTRL′ in the drawing). Each service instance may consume state information (denoted S in the drawing) and may produce state information (denoted S′ in the drawing) as an output. Each service instance may consume events (denoted E in the drawing) and may produce events (denoted E′ in the drawing). Each service instance may consume configuration information (denoted CFIG in the drawing) and may produce configuration information (denoted CFIG′ in the drawing). Each service instance may consume delivery information (denoted D in the drawing) and may produce delivery information (denoted D′ in the drawing).
It should be appreciated that not every service instance or kind of service instance needs to consume each kind of input (control, state, events, config, etc.) or to produce each kind of output. Furthermore, it should be appreciated that not every service instance needs to use or transform or modify any/all of its inputs (e.g., a service endpoint may pass information through without transformation of that information). So, e.g., with reference to FIG. 1B, in some cases CTRL=CTRL′ and/or S=S′ and/or E=E′, etc.
As used herein, in the context of data consumed or produced by a service, the term “state” refers to “state information,” the term “events” refers to “events information,” the term “config.” (or “configuration”) refers to “configuration information,” and the term “control” refers to “control information.” When used in the context of configuration information, the word “configuration” is sometimes abbreviated herein to “config” (without a period at the end of the word).
A producer of a certain kind of information is referred to as a “source” of that kind of information, and a consumer of a certain kind of information is referred to as a “sink” of that kind of information. Thus, e.g., a producer of state (or state information) may be referred to as a “state source,” a producer of configuration information may be referred to as a “config source,” etc.; a consumer of state may be referred to as a “state sink,” a consumer of configuration information may be referred to as a “config sink,” and so on.
Considering possible combinations of information flows provides a number of different ways to categorize services. A set of trivial service types (shown in FIG. 1C) may be defined by constraining each service to have one kind of information flow in one direction (i.e., to be a source or a sink of one kind of information). The five information categories delivery, configuration, control, events, and state (Table 1 above), give the ten trivial service types shown in FIG. 1C.
Using these trivial service types (FIG. 1C) as the basis, typical combinations of flows expected to occur in CD services may be defined, leading to the exemplary definition/taxonomy of the infrastructure services and (primary) delivery services shown in FIG. 1D. As shown in the drawing in FIG. 1D, CD services may be categorized as delivery sources and/or delivery sinks. A delivery source may be a config source, a control source, an event source, and/or a state source. A delivery source that is a config source is a delivery source of config information; a delivery source that is a control source is a delivery source of control information, a delivery source that is an event source is a delivery source of event information, and a delivery source that is a state source is a delivery source of state information.
A delivery sink may be a config sink, a control sink, an event sink, and/or a state sink. A delivery sink that is a config sink is a delivery sink of config information; a delivery sink that is a control sink is a delivery sink of control information, a delivery sink that is an event sink is a delivery sink of event information, and a delivery sink that is a state sink is a delivery sink of state information.
A minimal CD service is an event source and a control sink. That is, a minimal CD service is a delivery source of event information and a delivery sink of control information.
A (primary) delivery service is a minimal CD service (and thus inherits the taxonomic properties of a minimal CD service).
Thus, a configuration service may be categorized, according to the taxonomy in FIG. 1D, as a config source, and a config sink. A configuration service may also be categorized as a minimal CD service, whereby it is also categorized as an event source and a control sink. A configuration service is a delivery source (of config information) and a delivery sink of config information.
A control service may be categorized, according to the taxonomy in FIG. 1D, as a minimal CD service (and thereby an event source and a control sink), as a config sink, and as a control source. A control service is a delivery sink of config information and a delivery source of control information.
A reducer service may be categorized, according to the taxonomy in FIG. 1D, as a minimal CD service (and thereby an event source and a control sink), and as an event sink. A collector service may be categorized, according to the taxonomy in FIG. 1D, as a minimal CD service (and thereby an event source and a control sink), and as an event sink, a state source, and a state sink.
Caching services, rendezvous services, object distribution services, and compute distribution services are each (primary) delivery services, and are therefore minimal CD services, according to the exemplary taxonomy in FIG. 1D.
As may be seen from the diagram in FIG. 1D, in some aspects to be a CD service means to be enmeshed in the network of other CDN services. The Minimal CD Service in the diagram is both a Control Sink and an Event Source, meaning that all CDN services consume control information and generate events.
Those of ordinary skill in the art will realize and understand, upon reading this description, that this example taxonomy shown in FIG. 1D should be taken as a general guideline for naming services in useful ways that capture their essential similarities and differences, though it should not be used to limit the scope of the system in any way. While the taxonomy captures the names and definitions of idealized services, it should be appreciated that actual service implementations may stray from these constraints for practical reasons. Most actual infrastructure services will involve more information exchanges than shown above, for example. For example, control services may consume state information from collectors, and primary delivery services may consume both event streams and collector state. These variations may be considered subtypes of the versions shown earlier. A more realistic set of information flows between the basic CD service types is shown in FIG. 1E (discussed below). This set of relationships can be considered as existing between individual services or between entire subnetworks of homogeneous services (as can be seen by comparing the diagrams in FIG. 1E and FIG. 1F).
Those of ordinary skill in the art will realize and understand, upon reading this description, that several kinds of delivery services are referred to herein (as noted by the “Abstract” prefix in “(Abstract) Delivery” above). When not explicitly stated, the kind of delivery service may be determined from the context.
The (abstract) delivery service category is an umbrella term for all information exchanged by services and clients, reflecting the fact that all services deliver information. This observation leads to the taxonomy of information flows shown in FIG. 1G, where each of the other four types of information (config, control, events, and state) may be considered as special cases of (abstract) delivery information.
Unless stated otherwise or apparent from the context, in the rest of this description, however, a delivery service refers to one that is providing one of the (primary) delivery services that CDN subscribers/customers use (e.g., caching and rendezvous). Those of ordinary skill in the art will realize and understand, upon reading this description, that this distinction is arbitrary, and may change depending on the set of services offered to subscribers/customers. The offered set of services need not be limited to the current set of primary deliver services
The last service variant is (controlled) delivery, referring to any service that is being controlled by the network. Those of ordinary skill in the art will realize and understand, upon reading this description, that it may sometimes be useful to distinguish the service being controlled from the services doing the controlling, even though all services in the CDN are controlled by it.
Logical and Physical Information Flows
Each information flow between two interacting services will typically have an associated direction (or two). The direction of arrows in most of illustrations here is intended to represent the primary direction in which information flows between a source and a sink, and not the physical path it takes to get there.
For example, the left side of FIG. 1H depicts a logical flow of information across three services (config service to control service to controlled service). It should be appreciated, however, that the flow depicted in the drawing does not necessarily imply a direct exchange of information between the various services. The right side of FIG. 1H shows an example of an actual path through which information might flow, involving intermediate delivery networks (in this example, two specific intermediate delivery networks, object distribution service(s) for the config information from the config service to the control service, and caching service(s) for the control information from the control service to the controlled service, in this example). It should also be appreciated that the level of description of the right side of the FIG. 1H is also a logical representation of the data paths for the config and control information.
In addition, those of ordinary skill in the art will realize and understand, upon reading this description, that whether logical or physical, information flow arrows usually do not specify any protocol(s) involved for the information exchange or which side initiates the conversation. Multiple protocols are conceivable and are contemplated herein, and, in many cases, the same application level protocol could be applied in multiple ways, e.g., where either side may push or pull. An exception to this is when a particular protocol is itself a defining feature of a service (for example, as may be the case with primary delivery services).
Example CDNs
In some aspects, a CDN may be considered to exist in the context of a collection of origin servers provided by (or for) subscribers of the CDN service, a set of end-user clients of the content provided by subscribers through the CDN, a set of internal tools (e.g., tools that provision, configure, and monitor subscriber properties), an internal public-key infrastructure, and a set of tools provided for use by subscribers for direct (“self-service”) configuration and monitoring of the service to which they are subscribing (see, e.g., FIG. 1I). It should be appreciated that not every CDN need have all of these elements, services, or components.
For the purposes of this description, all services on the edge of and within the CDN cloud shown in FIG. 1I may be considered part of an exemplary CDN. These services may be distinguished from those outside the boundary in that they are themselves configured and controlled by other services within the CDN.
A CDN may thus be considered to be a collection of interacting and interconnected (or enmeshed) services (or service instances), along with associated configuration and state information. FIG. 1J depicts a logical overview of an exemplary CDN 1000 which includes services 1002, configuration information 1004, and state information 1006.
The services 1002 may be categorized or grouped based on their roles or the kind(s) of service(s) they provided (e.g., as shown in FIG. 1A). For example, as shown in FIG. 1J, an exemplary CDN 1000 may include configuration services 1008, control services 1010, collector services 1012, reducer services 1014, and primary delivery services 1016. Recall that, as used herein, for service type T, as used herein, the phrase “T services” refers to the collection of services of type T, regardless of whether or how those services are connected. Thus, e.g., the reducer services 1014 refer to the collection of all reducer service instances, regardless of whether the corresponding reducer service instances are actually connected, and, if connected, regardless of how they are connected.
The configuration services 1008 may include, e.g., services for configuration validation, control resource generation, etc. The control services 1010 may include, e.g., services for control resource distribution, localized feedback control, etc. The collector services 1012 may include, e.g., services for monitoring, analytics, popularity, etc. The reducer services 1014 may include, e.g., services for logging, monitoring, alarming, analytics, etc. The primary delivery services 1016 may include, e.g., services for rendezvous, caching, storage compute, etc.
Those of ordinary skill in the art will realize and understand, upon reading this description, that different and/or other categorizations of these services may be applied. In addition, those of ordinary skill in the art will realize and understand, upon reading this description, that the examples listed above for the various groups of services are merely exemplary, and that any particular category may include different and/or other services.
Roles and Flavors
The various CD services that a particular machine is running on behalf of the CDN, or the various roles that a machine may take on for the CDN, may be referred to as the flavor of that machine A machine may have multiple flavors and, as will be discussed, a machine may change flavors.
Provisioning and configuration of machines is described in greater detail below.
In some implementations, groups of services (corresponding, e.g., to the services needed by a particular kind of CDN node) may be named, with the names corresponding, e.g., to the flavors.
The role(s) that a machine may take or the services that a machine may provide in a CDN include: caching services, rendezvous services, controlling services, collecting services, and/or reducing services.
As used herein, one or more machines running a caching service may also be referred to as a cache; one or more machines running a rendezvous service may also be referred to as a rendezvous mechanism or system, one or more machines running control services may also be referred to as a controller; one or more machines running collecting services may also be referred to as a collector or collector mechanism; and one or more machines running a reducer services may also be referred to as a reducer or reducer mechanism.
CD Service Interactions
FIG. 1E shows the logical connectivity and flow of different kinds of information (event, control, and state information) between service endpoints of the various services or kinds of services of an exemplary CDN (based, e.g., on the categorization of services in FIG. 1J). As shown in FIG. 1E, configuration service instance endpoints (corresponding to configuration services 1008 in FIG. 1J) may provide configuration information to control service endpoints (corresponding to control services 1010 in FIG. 1J).
Control service instance endpoints may provide control information (C1) to collector service instance endpoints (corresponding to collector services 1012 in FIG. 1J), control information (C2) to reducer service endpoints (corresponding to reducer services 1014 in FIG. 1J), and control information (C3) to delivery service instance endpoints (corresponding to all delivery services, including primary services 1016 in FIG. 1J). Control services endpoints may also provide control information (C4) to other control services endpoints and control information (C5) to configuration service endpoints. The flow of control information is shown in the drawing by solid lines denoted with the letter “C” on each line. It should be appreciated that the letter “C” is used in the drawing as a label, and is not intended to imply any content or that the control information on the different lines is necessarily the same information.
As also shown in FIG. 1E, configuration service endpoints, control service endpoints, collector service endpoints, reducer service endpoints, and services endpoints, may each provide event data to reducer service endpoints. Reducer service endpoints may consume event data from the various service endpoints (including other reducer service endpoints) and may provide event data to collector service endpoints. The flow of event information is shown in the drawing by dotted lines denoted with the letter “E” on each line. It should be appreciated that the letter “E” is used in the drawing as a label, and is not intended to imply any content or that the event information on the different lines is necessarily the same event information.
Various components (i.e., service endpoints) may consume and/or produce state information. For example, collector service endpoints may produce state information for other service endpoints, e.g., state information S1 for reducer service endpoints, state information S2 for configuration services endpoints, state information S3 for control service endpoints, state information S4 for collector service endpoints, and state information S5 for delivery service endpoints. The flow of state information is shown in the drawing by dot-dash lines denoted with the letter “S” on each line. It should be appreciated that the letter “S” is used in the drawing as a label, and is not intended to imply any content or that the state information on the different lines is necessarily the same state information.
As can be seen from the flow of information (event data, control data, and state data) in the diagram in FIG. 1E, various services or components of the CDN can provide feedback to other services or components. Such feedback may be based, e.g., on event information produced by the components. The CDN (services and components) may use such feedback to configure and control CDN operation, at both a local and a global level.
FIG. 1K shows aspects of the flow in FIG. 1E (without the configuration services, with various flow lines removed and with some of the branches relabeled in order to aid this discussion). As shown in FIG. 1K, a particular service endpoint 1016-A may provide event data (E) to a reducer endpoint service 1014-A. The reducer endpoint service may use this event data (and possibly other event data (E′), e.g., from other components/services) to provide event data (E″) to collector endpoint service 1012-A. Collector service 1012-A may use event data (E″) provided by the reducer endpoint service 1014-A to provide state information (S) to a control endpoint service 1010-A as well as state information (denoted S local) to the service endpoint 1016-A. FIG. 1K shows particular components/endpoints (a service endpoint) in order to demonstrate localized feedback. It should be appreciated, however, that each type of service endpoint (e.g., control, collector, reducer) may provide information to other components/service endpoints of the same type as well as to other components/service endpoints of other types, so that the control feedback provided to the service endpoints may have been determined based on state and event information from other components/service endpoints.
Those of ordinary skill in the art will realize and understand, upon reading this description, that the information flow (and thus any feedback loops) shown in FIGS. 1E and 1K may apply equally at local and global levels, and may apply to any and all CDN services and components. Thus, as shown in FIG. 1L, information may flow between the various CDN components shown in FIG. 1J in the same manner as information flows between service instance endpoints.
Event information from each kind of service may be provided to reducer services 1014 from each of the other kinds of services. The reducer services 1014 may provide event information to the collector services 1012. Based at least in part on event information provided by the reducer services 1014, the collector services 1012, in turn, may provide state information to control services 1010, configuration services 1008, reducer services 1014, and primary services 1016. Based at least in part on state information provided by collector services 1012, the control services 1010 may provide control information to the other services.
FIG. 1E shows canonical service interactions between individual service instances of various types, whereas FIG. 1L shows interactions and information flows between groups of services of the same type or between classes of service types. It should therefore be appreciated that various boxes (labeled 1008, 1010, 1012, 1014, and 1016) in FIG. 1L may represent multiple services/components of that type.
The endpoints of each kind of service (caches, rendezvous, collectors, reducers, control) may be organized in various ways. In general, the endpoints of each kind of service form a network comprising one or more sub-networks of those endpoints. Thus, a CDN may include at least one cache network of cache services, at least one rendezvous network of rendezvous services, at least one collector network of collector services, at least one reducer network of reducer services, and at least one control network of control services. Each of these networks may be made up of one or more sub-networks of the same type of services. The configurations and topologies of the various networks may be dynamic and may differ for different services. Those of ordinary skill in the art will realize and understand, upon reading this description, that a CDN need not have all of the kinds of services listed or described here.
Each box showing services in FIG. 1L (i.e., boxes labeled 1008, 1010, 1012, 1014, and 1016) may, e.g., comprise a network (one or more subnetworks) of services or components or machines providing those services.
Thus, e.g., the box labeled reducer services 1014 may comprise a network of reducers (or machines or components providing reducer services). That is, the reducer services 1014 may comprise a reducer network (one or more subnetworks) of reducer services, being those subnetworks of the CDN consisting of all service instances of type “reduce.”
Similarly, the box labeled collector services 1012 may comprise a network of collectors (or machines or components providing collector services). That is, the collector services 1012 may comprise a network (one or more subnetworks) of collector services (the collector network), being those subnetworks of the CDN consisting of all service instances of type “collector.” Similarly, control services 1010 may comprise a control network (one or more subnetworks) of control services, being those subnetworks of the CDN consisting of all service instances of type “control.” Similarly, config services 1008 may comprise a config network (one or more subnetworks) of config services, being those subnetworks of the CDN consisting of all service instances of type “config,” and similarly, the delivery services 1016 (which includes cache services and rendezvous services) may comprise a network (one or more subnetworks) of such services. FIG. 1F shows exemplary information flows between homogeneous service-type networks.
Thus, event information may flow from any delivery service (1016) via a network of reducer services 1014 to a network of collector services 1012. Any of the reducer services in the network of reducer services 1014 may provide event information to any of the collector services in the network of collector services 1012. Any of the collector services in the network of collector services 1012 may provide state information to any of the reducer services 1014 and to control services 1010.
Thus are provided various feedback loops that, in an embodiment, operate in real time to control the various services.
Those of ordinary skill in the art will realize and understand, upon reading this description, that, as used herein, the term “real time” means near real time or sufficiently real time. It should be appreciated that there are inherent delays built in to the CDN (e.g., based on network traffic and distances), and these delays may cause delays in data reaching various components Inherent delays in the system do not change the real-time nature of the data. In some cases, the term “real-time data” may refer to data obtained in sufficient time to make the data useful in providing feedback.
Although the term “real time” has been used here, it should be appreciated that the system is not limited by this term or by how much time is actually taken for data to have an effect on control information. In some cases, real time computation may refer to an online computation, i.e., a computation which produces its answer(s) as data arrive, and generally keeps up with continuously arriving data. The term “online” computation is compared to an “offline” or “batch” computation.
Hybrid Services
Although services are generally described as having one role (e.g., delivery, rendezvous, collector, reducer, etc.), those of ordinary skill in the art will realize and understand, upon reading this description, that hybrid services may be formed by combining the functionality of various services. Hybrid services may be formed from services of different types or of the same type. For example, a hybrid service may be formed from a reducer service and a collector service. Hybrid services may be formed from one or more other services, including other hybrid services. Each device may run one or more services, including one or more hybrid services.
Events & Event Information
As noted, each service may produce information corresponding to events relating to that service (e.g., an event sequence corresponding to events relating to that service). An event is information (e.g., an occurrence) associated with an entity and an associated (local) time for that information. Thus, at a local level, i.e., at an entity (e.g., service or device or machine) that produces an event, an event may be considered as a <time, information> pair. An event stream is an ordered list of events, preferably time ordered, or at least partially time ordered. The time associated with an event is, at least initially, presumed to be the time on the entity on which that event occurred or a time on the entity on which the information associated with that event was current, as determined using a local clock on or associated with that entity. Events in event streams preferably include some form of identification of the origin or source of the event (e.g., an identification of the entity originally producing the event). Thus, outside of the entity that produces an event, an event may be considered as a tuple <entity ID; time, information>, where “entity ID” identifies the entity that produced the event specified in the “information” at the local time specified by the “time” field. Preferably the entity ID uniquely identifies the entity (e.g., a service instance) within the CDN. The time value is time at which the event occurred (or the information was generated), as determined by the entity. That is, the time value is a local time of the event at the entity. In preferred implementations, local time is considered to be coordinated universal time (UTC) for all CDN entities/services.
The information associated with an event may include information about the status of an entity (e.g., load information, etc.), information about the health of an entity (e.g., hardware status, etc.), information about operation of the entity in connection with its role in the CDN (e.g., in the case of a server, what content it has been requested to serve, what content it has served, how much of particular content it served, what content has been requested from a peer, etc., and in the case of a DNS service, what name resolutions it has been requested to make, etc.), etc. Those of ordinary skill in the art will realize and understand, upon reading this description, that different and/or other occurrences or items of information may be included in events.
An event stream is a sequence of events, preferably ordered. Streams are generally considered to be never ending, in that they have a starting point but no assumed endpoint.